@tjfontaine You may want to chime in here.

I guess the question is if IO should try and be serviced before the first queued immediate, if there are multiple queued immediates I don't see the placement explicitly after nextTick providing much besides saving a global timer allocation.

As far as the 1ms displacement, we could requeue the timer instead of relying on libuv to do it.

diff --git a/lib/timers.js b/lib/timers.js
index 897b64f..1009776 100644
--- a/lib/timers.js
+++ b/lib/timers.js
@@ -281,7 +281,7 @@ Timeout.prototype.close = function() {


 var immediateTimer = null;
-var immediateQueue = { started: false };
+var immediateQueue = {};
 L.init(immediateQueue);


@@ -294,10 +294,7 @@ function lazyImmediateInit() { // what's in a name?

 function processImmediate() {
   var immediate;
-  if (L.isEmpty(immediateQueue)) {
-    immediateTimer.stop();
-    immediateQueue.started = false;
-  } else {
+  if (!L.isEmpty(immediateQueue)) {
     immediate = L.shift(immediateQueue);

     if (immediate.domain) immediate.domain.enter();
@@ -305,6 +302,8 @@ function processImmediate() {
     immediate._onTimeout();

     if (immediate.domain) immediate.domain.exit();
+
+    immediateTimer.start(0, 0);
   }
 };

@@ -325,8 +324,7 @@ exports.setImmediate = function(callback) {

   if (!immediateQueue.started) {
     lazyImmediateInit();
-    immediateTimer.start(0, 1);
-    immediateQueue.started = true;
+    immediateTimer.start(0, 0);
   }

   if (process.domain) immediate.domain = process.domain;
@@ -343,9 +341,4 @@ exports.clearImmediate = function(immediate) {
   immediate._onTimeout = undefined;

   L.remove(immediate);
-
-  if (L.isEmpty(immediateQueue)) {
-    immediateTimer.stop();
-    immediateQueue.started = false;
-  }
 };

The results from the test script then are

iter= 100 , elapsed time= 3 , ave= 0.03
iter= 200 , elapsed time= 4 , ave= 0.02
iter= 300 , elapsed time= 1 , ave= 0.0033333333333333335
iter= 400 , elapsed time= 1 , ave= 0.0025
iter= 500 , elapsed time= 2 , ave= 0.004
iter= 600 , elapsed time= 2 , ave= 0.0033333333333333335
iter= 700 , elapsed time= 2 , ave= 0.002857142857142857
iter= 800 , elapsed time= 2 , ave= 0.0025
iter= 900 , elapsed time= 3 , ave= 0.0033333333333333335
iter= 1000 , elapsed time= 2 , ave= 0.002

@tjfontaine I drew a figure below to show the semantics of setImmediate in this PR. I think it is clearly understandable for the order of execution.

I understand the flow, I just don't necessarily see how this influences much. Unless--as I said before--it's important that we service IO before the execution of the first queued immediate

@tjfontaine I think the problems would occur between setImmediate and other timers(setTimeout/setInterval). In the current setImmediate, before fix 1msec delay, the following code shows an odd result.

var i = 0, j = 0, max = 5;
var tmout = setInterval(function() {
  console.log('setInterval :', i++);
  if (i > max) clearTimeout(tmout);
}, 0);
(function f() {
  setImmediate(function () {
    console.log('setImmediate :', j++);
    if (j > max) return;
    f();
  });
})();

> ./node ~/test.js
setImmediate : 0
setInterval : 0
setInterval : 1
setImmediate : 1
setInterval : 2
setImmediate : 2
setInterval : 3
setImmediate : 3
setInterval : 4
setImmediate : 4
setInterval : 5
setImmediate : 5

The order of execution is changed in Linux. On Windows it varies time by time. This is because setImmediate and setInterval have the same timeout value and depends its order of execution on their pointer value.

I tried to put start_id on timer handles at every uv_timer_start for the second index to compare each elements in RBTree of timers but I found that moving setImmediate from timer to uv_check is simple and clearly understandable rather than it.

I do not disagree there is a deficiency in uv timers, and I'm sure they'll want to address that, but I think simply fixing my 1ms requeue mistake is sufficient compared to making setImmediate behave differently than the other timers.

But I yield to @bnoordhuis and his judgement.

But I yield to @bnoordhuis and his judgement.

Me, too.

I tried to put start_id on timer handles at every uv_timer_start for the second index to compare each elements in RBTree of timers but I found that moving setImmediate from timer to uv_check is simple and clearly understandable rather than it.

The patch is here. shigeki/libuv@50d55ed
But I don't think it is sophisticated.

I'm not sure what the best behavior is here. Homogeneity is important (i.e. don't be different from other timers) but having a check watcher makes it nicely predictable.

@isaacs, @piscisaureus Opinions?

I've just rebased this to the current master and fixed a small bug.
@isaacs @piscisaureus @bnoordhuis Any more opinions? I'm sure that moving setImmediate to uv_check() is beneficial because it avoids future issues caused by racing conditions between timers and setImmediate.

@bnoordhuis node-v0.10 is around the corner. I wonder if this 1msec delay on setImmediate() cause bugs, they would be hard for users to be identified. I will not hold this PR any more and @tjfontaine 's patch for not using a repeat timer is still valid. So please fix it before releasing node-v0.10.

For the record, I like the idea of a check handle (pending joyent/libuv#699) and no one seems to really disagree. I move to go with your approach.

Oh, thanks very much, Ben. I'm going to rebase this to work on the current master.

Landed on master. Thanks, @shigeki! By the way, I really love those process loop diagrams. Do you have them collected somewhere? Can we use them in the node documentation?

@bnoordhuis As far as I can tell, libuv#699 is an issue whether we land this or not, and we can fix it whenever. Moving forward.

@isaacs Thanks. It's my pleasure to have your offer. I wrote a kind of more simpler diagram in the process.nextTick chapter of a Node book in Japanese for node-v0.8. I will check it again and submit PR to a doc.